* feat: add suppoort for responses api

* fix: test

* fix: black

* fix: test - hopefully

* fix: test - hopefully #2

* fix: test - hopefully #3

* fix: test - hopefully #4

* fix: greptaile catch

* fix: mypy is not my friend

* fix: isort usort weallsort

* fix: noredef

* fix: mypy baseline

* fix: mypy

* fix: mypy

The sdk-specs `flush` contract requires an explicit flush to bypass the
batching thresholds: "Do not wait for `flushAt` or `flushInterval`;
attempt delivery now" (openspec/specs/flush/spec.md, Requirement
"Canonical flush behavior", Behavior #2).

`Consumer.next()` accumulates until it has `flush_at` items or
`flush_interval` elapses, and nothing connected `flush()` to a consumer
parked mid-batch — `_Lane.flush()` only blocked on `queue.join()`. So a
consumer holding a partial batch kept waiting for more events and the
caller waited with it: on defaults, `capture()` + `flush()` took ~5s.
Worse, `flush()` defaults to `timeout_seconds=10`, so any `flush_interval`
above that made the default `flush()` give up and deliver nothing.

Add `DrainSignal`, a generation counter shared by a lane and its
consumers. `flush()` and `join()` bump it; while a request is outstanding
a consumer takes only what is already queued and uploads as soon as the
queue comes up empty, which is when it marks the request served. A
consumer already holding a partial batch waits in slices so it notices a
request that lands while it is parked; an idle consumer still parks for
the whole interval, since a new put wakes its get() anyway.

Timer-based batching without an explicit flush is unchanged: a slice
expiring only re-arms the wait, and the batch window still closes on
`flush_at`, the batch size limit, or a full `flush_interval`.


Generated-By: PostHog Code
Task-Id: 2bc2b5c5-03be-4da2-b7df-97c3364b33c9